Time optimized replacement of a software application

ABSTRACT

The invention relates to a method for replacing old software ( 10 ) that is in use with new software ( 12 ), which permits the maximum availability of the software. Said method is subdivided into a preparation phase (V) and an active phase (A). The preparation phase (V) take place during the operation of the old software ( 10 ). The active phase (A) is merely characterized by the execution of a MOVE command.

BACKGROUND OF THE INVENTION

The present invention relates to a method for performing a status changeon at least one computer from an actual condition to a target condition,the status change relating in particular to replacement or first-timecommissioning of software or of a software package.

The use of software is subject to continuous further development, withthe result that applications that already exist and are in operationmust be adapted to suit new requirements (e.g., increased hardwareperformance) or upgraded. Consequently, the existing application in usehas to be replaced by a later version, an upgrade/update or with acorrected version (patch).

There are basically several ways of installing software on a computer.Formerly, a set of diskettes was used, the first diskette generallycontaining a setup program and a compressed file. The decompressedfile(s) is/are then copied to a destination directory on the targetsystem. The setup program guides the user through the installationroutine and can in some cases additionally modify certain configurationfiles of the target system.

Today, a CD can be used which enables a similar procedure to be followedand provides more storage space.

Additionally known is the use of shells which automatically extract anassociated file tree and store it in a selectable directory. If softwareis not to be installed for the first time, but already installedsoftware is to be reinstalled, there are basically two options:

1. After deinstalling the old package, the new package is completelyreinstalled. The advantage of this method is that all the newlyinstalled files also have de facto the same version, and errors due toerroneously unchanged files can be eliminated. The major disadvantage ofthis method is that it is very time-consuming.

2. No deinstallation takes place, but only the parts that are differentin the new version are reinstalled. Although this is faster, theswapping of data between the old and new files often results in errors.

All the known installation techniques are certainly very time-intensiveand require a lengthy period during which neither the old nor the newsoftware can be run.

For particularly time-critical applications, such as in thetelecommunications and database fields, time-optimized replacement ofapplication software is indispensable in order not to disrupt operationof the entire system.

With regard to the abovementioned areas of use which require virtuallycontinuous coverage of the application, it is unacceptable for theapplication to be inoperable for a lengthy period due to the necessarysoftware replacement.

A highly time-optimized status change is not only critical for softwarereplacement, however, but also applies if certain system variables areto be changed or if certain peripherals and/or hardware components areto be replaced by others, with the result that, for example, the use ofother drivers becomes necessary. Basically, time-optimized replacementis necessary if other processes are using the current software to bereplaced.

To date, the status in terms of software replacement has beenimplemented by taking the existing software out of operation, replacingit by installing new software and then re-starting the applicationand/or the system.

This method has been found to be very disadvantageous for thetime-optimization reasons described above; the method for replacingsoftware has until now been adopted from the general use of applicationsoftware in other areas which have a much greater time tolerance. If,for example, a drawing program is to be replaced by a new version of thesame, a brief unavailability of the application would be acceptable.However, this is not the case in the telecommunications field,particularly for carrier-grade systems, as these require maximumavailability.

An object of the present invention is, therefore, to create a methodallowing a time-optimized status change, in particular a time-optimizedreplacement of software applications, and one which can be automated.The object is, in particular, to create a method for replacingapplications on individual computers in a multi-computer network.

SUMMARY OF THE INVENTION

Such object is achieved by the method described above which issubdivided into a preparation phase and a subsequent active phase, thepreparation phase being carried out in the actual condition andincluding the following steps:

-   -   registering control information relating to the target        condition;    -   automatically generating at least one script from the control        information;    -   saving the data for the target condition to an intermediate        (cache) directory;    -   and wherein the status change is performed during the active        phase by terminating operation in the actual condition and        applying the script to make the data for the target condition        available in a destination directory without all the data for        the target condition having to be physically moved.

Such object is achieved in particular, in that no physical movement ofthe data takes place in the active phase; specifically, no movement ofthe entire software package with its associated directory tree.

In contrast to the current method of status change and softwarereplacement adopted from other areas of installation, it has been foundto be very advantageous for the availability of the relevant softwarethat the time required for the status change can be significantlyreduced. This is achieved by subdividing the area of softwareinstallation into two phases: a preparation phase executed while theactual condition still occurs; i.e., during operation of the oldsoftware or during operation without the new software being installed.The second phase, a so-called active phase, is used for direct executionof the status change without data transfer being necessary. By bringingforward the preparation phase, the time-critical active phase can belimited to the execution of only one or more move instructions, aftertermination of the actual condition and to initiate the targetcondition. Therefore, by bringing forward significant parts of theinstallation process, such as loading operations and processes forgenerating the appropriate environment, the time to the start of thetarget condition and also the shutdown time can be minimized. It is thelatter that is of particular importance, as the period of inactivity ofalready installed software that is to be replaced by an upgrade, anupdate or a patch should be as brief as possible.

This results in significantly improved downtimes of the softwareemployed, particularly in the area of applications for network operatorsand service providers.

A further advantage also lies in the automatability of the method,particularly in that time-optimized scripts can be generatedautomatically and in the generation of the associated environment forthe software in the target condition or for the current version of thesoftware. This is made possible by subjecting the actual condition toanalysis in which certain system parameters (e.g., environmentvariables) are automatically registered. Dynamically adapted, automaticinstallation can then take place, as the scripts for performing theinstallation take the registered system parameters into account. Todate, dynamically adapted installation method has been unknown and isadvantageous not merely for time reasons, as the necessary interactiveentry of information does not allow a time-optimized method.

This also results in less proneness to errors than in the presentsystems, as the automatically produced path names are generatedfaultlessly and coincide with the corresponding directories. Errors havearisen, for example, due to the fact that when upgrading an applicationon a Windows system, parts or areas of the operating system (e.g., theDLL files), are modified by installation of the application software.This can give rise to a situation in which DLL files exist in the oldversion and in the new version. However, no tracing for the overwritingof DLL files takes place. With a sequence of installations anddeinstallations, incongruities can then arise.

In the preferred embodiments of the present invention, the method forperforming a status change is applied to computers used in the area ofcarrier-grade systems in the telecommunications field.

A particularly advantageous embodiment of the present invention relatesto cluster computers. To increase computing power and advantageouslyinfluence other system parameters, clusters are often used; e.g., agroup of networked computers that are assigned the same task. So-calledstandby clusters or availability clusters are used in order to be able(as the name suggests) to optimize the availability of a system. Forexample, the cluster could consist of two machines, one of whichperforms a specific task assigned to it. The other machine is in standbymode. Only if the first machine indicates that problems are occurring(e.g., a hardware defect or a software fault) will the second machinetake over the jobs of the first. (No load sharing occurs). As such,there is an inactive or standby condition of a machine or, in otherconcepts, of a network of machines.

This standby condition, the so-called cluster redundancy, is used insuch a way with the present invention that the status change onlyaffects the inactive side of the cluster, enabling availability to beincreased still further.

In a further advantageous embodiment of the present invention, “UNIX” isused as the operating system. This move instruction is then executed bythe use of one or a sequence of MOVE commands.

The MOVE command is therefore time-optimized, as no data is moved, butonly the top entry in the corresponding directory tree, the so-calledinode entry, is modified or redirected. As all the necessaryarrangements have been made in the preparation phase, only the MOVEcommand still has to be executed in the active phase using the methodaccording to the present invention.

It has been found to be extremely advantageous that the environment forthe relevant application can be automatically generated using the methodaccording to the present invention. For this purpose the software forthe target condition is stored under automatically generated path names.The advantage of this is that the corresponding and correctly configuredenvironment is activated automatically when the target condition is putinto operation.

The inventiveness is particularly evident in that an installation scriptis generated automatically and above all dynamically; the new package isaugmented with specific target system information, so that optimized andin particular time-optimized installation on the relevant target systemis possible without further system parameters having to be requestedand/or processed during the installation. The time optimization of thestatus change, particularly of software replacement, is therefore basedaccording to the present invention on the concept that the software tobe installed does not need to be moved during the active phase.

Additional features and advantages of the present invention aredescribed in, and will be apparent from, the following DetailedDescription of the Invention and the Figures.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 a is a schematic representation of a status change according tothe prior art.

FIG. 1 b is a schematic representation of a status change according tothe present invention.

FIG. 2 shows a flowchart for performing the status change according tothe present invention.

DETAILED DESCRIPTION OF THE INVENTION

The method is geared to replacing old software 10 that is in use withnew software 12 that is to be installed for the first time orre-installed.

The new software can be an update, an upgrade or a patch of the oldsoftware 10. However, it is also possible that the new software 12 to beinstalled has not yet been installed and a first-time installation is tobe achieved by the status change.

The method according to the present invention is characterized by twodirectly consecutive phases: in a preparation phase V, all the processesare executed which can be brought forward in time and can take placewhile the old software 10 is still in operation. In an active phase A,the replacement process is completed by relocating certain files anddirectories only. The active phase A ends with startup of the newsoftware 12.

FIGS. 1 a and 1 b refer to the change from actual to target condition.FIG. 1 a illustrates a software change according to a method from theprior art and FIG. 1 b relates to the method according to the presentinvention which is subdivided into the preparation phase V and theactive phase A.

By replacing or changing a program, a status change of the computer orsystem (of computers) is achieved. An actual condition 16 ischaracterized by operation of the old software 10. This actual condition16 is to be transformed into a target condition 18 characterized byoperation of the new software 12. By using the method according to thepresent invention, the time for the status change (i.e., the timebetween shutdown of operation of the old software 10 and startup of thenew software 12) is minimized.

In a preferred embodiment, the software is to be replaced on a computerof a SUN cluster 2.2.

To increase the availability of the software application, the clusterredundancy is utilized by performing the status change on the inactiveside of the cluster only, without interrupting software operation on theactive side.

The rough time sequence of an advantageous embodiment of the methodaccording to the present invention in respect of a UNIX computer willnow be explained with reference to FIG. 2.

In this connection it should be noted that other embodiments of thepresent present invention provide a modified sequence of the individualprocedural steps shown in FIG. 2, the steps illustrated in the firstthree boxes taking place in the software production phase and theremaining (five) steps being executed on the target machine.

To initiate the method, all the prerequisites for bringing about thetarget condition, particularly of the new software 12, are registered asshown in FIG. 2. During development or production of the softwarepackage, a so-called control file 20 is created in which controlinformation 22 is stored.

The control information 22 is packed together with the new software 12into a package 24 according to the known method from the prior art.

The control information relates, for example, to the required systemreaction during or after performance of the status change. It may berequired, for example, that no system reaction shall take place afterinstallation of the new software 12, or shutdown of the application orshutdown of the application including the basic software may berequired, namely of the intermediate layer between the application andthe operating system. Alternatively it can be specified that a completereboot shall take place.

The control information 22 of the package 24 is still used in thepreparation phase V in order to generate one or more scripts 26. Thesescripts 26 cause the replacement action to be executed in atime-optimized manner.

In addition, the new software 12 is stored under automatically generateddirectory names which are used as a cache directory. A dynamicassignment between the directory names and environment variables of thesoftware package then takes place.

The UNIX operating system provides the administrator with clearlydefined routines, such as the “package add” (pkgadd) and “packageremove” (pkgrm) routines which add a package or remove software from asystem as their names suggest. The format for UNIX software packages isdefined among other things by an “Application Binary Interface” (ABI).

To summarize, in the preparation phase V all the time-intensive commandsare executed in the background of current system operation in a cachedirectory (in FIG. 2 the term “cache directory” in the fifth step hasbeen abbreviated to “cache dir.”). Thus when the new software 12 hasbeen unpacked, it is installed in the cache directory—using, forexample, the “pkgadd” command. Scripts 26 are then generated forsubsequently performing the replacement of the old software 10 with thenew software 12—from the pkgadd control file “pkgmap”, for example. Thenthe environment for the new software 12 is automatically generated.

Only then is it necessary to shut down the old software 10, particularlythe network operator software. This point in time also defines thetransition from the preparation phase V to the active phase A. Aftershutdown of the old software 10, the scripts 26 are now in turnexecuted, depending on the embodiment selected, by executing a MOVEcommand or a sequence of MOVE commands.

Because of the preliminary steps in the preparation phase V, theexecution of a MOVE command or of a sequence of MOVE commands is nownecessary at this point in order to have the information stored in thecache directory available in the destination directory. After executionof this operation, the new software 12 is put into operation, the targetcondition 18 is attained and the active phase A is complete.

By executing the preparatory and time-intensive steps in the preparationphase V, the active phase A can be reduced to a minimal time period,which considerably increases system availability. Execution of thetime-intensive commands takes place in the preparation phase V; i.e., inparallel with the operation (of the old software 10) in the actualcondition 16. This period of time during the preparation phase V cantherefore be totally disregarded in terms of the non-availability of thesystem. As the present invention is based not least on the fact thatduring the actual condition 16 as many installation process as possibleare brought forward, the preparation phase V can occupy a longer periodof time than would be the case for a method according to the prior art.This does not impair availability, however, as the old software 10 stillcontinues to run during the actual condition 16. The system is onlyunavailable during the minimally short active phase A.

The time benefit according to the present invention therefore resultsfrom using a MOVE command or a sequence of MOVE commands, which onlychange the root of the file tree, the INODE, and do not move data. Thisis the difference between re-installation according to the presentinvention and that known in the prior art in which a complete copy ofthe data is generated.

An alternative embodiment of the present invention provides for the useof the method for non-UNIX systems and/or non-cluster systems.

The method according to the present invention additionally includesfurther options for performing the replacement process. For example, itcan be specified whether a system reaction is required afterincorporation of the new software 12 (for example a reboot, etc.). Inaddition, the necessary processes can be defined that are necessaryprior to unpacking of the new software 12 and/or after incorporation ofthe new software 12 in the destination directory but before restartingthe new software 12. This includes processes such as necessary dataconversions, link generation or the like. In addition, the environmentwhich is to be automatically activated in the target condition 18 can beset.

An important advantage in practice is that the environment of the newsoftware 12 to be installed is generated automatically. The user doesnot therefore need to be concerned with selecting the correctinstallation package and the method can operate on a fully automatedbasis.

In order not to lose the operable old software 10 (i.e., the actualcondition 16 prior to the replacement action), in the event of amis-controlled replacement action, there is additionally provided afall-back option involving a back-replacement of the software. Thismeans that the old actual condition corresponds to the new targetcondition and vice versa. For this purpose the old software 10 to bereplaced is saved to a backout directory. From this directory it is thenmoved again to the destination directory. This additional backup measureensures that no data can be lost.

However, the method is frequently used to cause a patch for the softwareapplication to be installed automatically. The correction program, theso-called patch, can therefore be automatically installed in therelevant version and with the appropriate environment.

Although the present invention has been described with reference tospecific embodiments, those of skill in the art will recognize thatchanges may be made thereto without departing from the spirit and scopeof the present invention as set forth in the hereafter appended claims.

1. A method for performing a status change on at least one computer,wherein the computer is a computer within a cluster, from an actualcondition to a target condition, the status change relating to one ofreplacement and initial operation of software, the method comprising thesteps of: subdividing the method into a preparation phase and asubsequent active phase, wherein the preparation phase is executedduring operation of the actual condition and the status change iseffected during the active phase, wherein the preparation phaseincludes: registering control information relating to the targetcondition; automatically generating at least one script from the controlinformation; and saving data for the target condition to a cachedirectory; and wherein the active phase includes: terminating operationin the actual condition; and applying the script via which the data forthe target condition is relocated from the cache directory to adestination directory, wherein execution of the script istime-optimized.
 2. A method for performing a status change as claimed inclaim 1, wherein an appropriate environment for the target condition isautomatically generated.
 3. A method for performing a status change asclaimed in claim 1, wherein the data for the target condition is stored,during the preparation phase, under automatically generated path names.4. A method for performing a status change as claimed in claim 1,wherein at least the active phase occurs on inactive sides of thecluster computers.
 5. A method for performing a status change as claimedin claim 1, wherein the computer is a UNIX computer.
 6. A method forperforming a status change as claimed in claim 5, wherein uponcompletion of the active phase, the data for the target condition is nolonger in the cache directory but is accessible in the destinationdirectory by renaming a data tree route via a MOVE command.
 7. A methodfor performing a status change as claimed in claim 1, the method furthercomprising the step of automatically restoring the actual conditionafter performing the status change by generating a backout packageduring installation of a package.
 8. A method of performing a statuschange as claimed in claim 1, wherein the data for the target conditionrelates to a software package in which control information has beenincorporated.
 9. A method of performing a status change as claimed inclaim 8, wherein the software package is unpacked in the cachedirectory.
 10. A method of performing a status change as claimed inclaim 1, wherein the status change involves installing new software forthe first time.
 11. A method of performing a status change as claimed inclaim 1, wherein the status change involves re-installing old software,the re-installation involving at least one of an upgrade and an update.12. A method of performing a status change as claimed in claim 1,wherein the status change involves installing a patch for old software.13. A method of performing a status change as claimed in claim 1,wherein the status change is performed automatically.
 14. Acomputer-readable storage medium having a program incorporating softwarecode portions for performing, upon execution by a processor, a statuschange on at least one computer, wherein the at least one computer is acomputer within a cluster, from an actual condition to a targetcondition, the status change relating to one of replacement and initialoperation of software, with the program being subdivided into apreparation phase and a subsequent active phase, the software codeportions comprising: registering in the preparation phase and during theoperation of the actual condition, control information relating to thetarget condition; automatically generating, in the preparation phase,and during the actual condition, at least one script from the controlinformation; saving, in the preparation phase and during the actualcondition, data for the target condition to a cache directory;terminating, during the active phase, operation in the actual condition;and applying, during the active phase, the script via which the data forthe target condition is relocated from the cache directory to adestination directory, wherein execution of the script istime-optimized.